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SYSTEMS AND METHODS FOR COMBINED PROTOCOL 
PROCESSING PROTOCOLS 

FIELD OF THE INVENTION 

The present invention relates generally to data communication and, more 
particularly to systems and methods used to process and respond to data 
packets according to different protocols. 

BACKGROUND OF THE INVENTION 

Communication networks permit communication devices, such as per- 
sonal computers, servers, laptops, personal digital assistants (PDAs), and 
other similar devices, to communicate with one another. Recently, house- 
hold appliances have begun including micro-controllers and/or microcom- 
puters that allow these appliances to communicate over a communication 
network, such as the Internet. 

Communication over these networks in often goverened by a packetiza- 
tion protocol and a corresponding packet exchange protocol that specifies 
what the communication devices must or must not do under specific circum- 
stances. These protocols are often defined according to a layered architecture. 
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These protocols are defined under the relavant standards, as applicable to 
the domains in which the communication devices operate. 

Packetization and packet exchange protocols usually require that a com- 
munication device involved in data communications transmit a data file as 
a series of discrete packets. Such packetization is govered by the protocols 
specified as a part of the transport layer protocols. For example, the stream 
of one or more packets may be govered by protocols such as Transmission 
Control Protocol (TCP) or the User Datagram Protocol (UDP) and all re- 
lated protocols, as specified in "Requirements for Internet Hosts - Commu- 
nication Layers," RFC1122, ftp://ftp.isi.edu/in-notes/rfcll22.txt, October 
1989. The packets produced in accordance with these protocols are trans- 
mitted in accordance with the procedures of the network layer and data link 
layer protocols. 

The packet format specified by the Transmission Control Protocol and 
the User Datagram Protocol are different. The procedures specified in the 
Transmisson Control Protocol (TCP) and User Datagram Protocol (UDP) 
for processing the information in the headers of these packets and for replying 
to the packets are different. In the conventional implementations, the pro- 
cedures in accordance with these protocols are implemented using distinct 
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systems and/or distinct methods. 

Some communication devices, such as mini-computers, micro-controllers, 
and microcomputers, lack sufficient local memory to store the information 
associated with the procedures in these protocols. Some of these devices lack 
the memory resources to store the instructions for the distinct processing of 
distinct packetization protocols. Some of these devices lack the logic circuit 
resources to perform the distinct processing requirements of these distinct 
protocols. 

Therefore, there exists a need for systems and methods that enable com- 
munication devices with limited memory capacity or logic circuitry to com- 
municate over a network with one or more distinct protocols. 

SUMMARY OF THE INVENTION 

Systems and methods consistent with the present invention address this 
and other needs by enabling a communication device to transmit data packets 
in accordance with two or more distinct protocols without requiring a large 
local memory to store the two or more distinct processing instructions and 
without requiring a large logic circuitry to contain the two or more distinct 
processing means. 
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In accordance with the purpose of the invention as embodied and broadly 
described herein, a method of transmitting data in accordance with one of 
two or more protocol specifications and in accordance with one of two or more 
packet formatting specifications is provided. The method includes requiring 
the data fields of a data packet to be formatted in accordance with one or 
more additional constraints, over and above the constraints as specified in 
the protocol specification corresponding to this packet. The method also 
includes a method for deriving and specifying these additional one or more 
constraining specifications that are to be applied to the formatting of the 
packets. 

In another implementation consistent with the present invention, a system 
for transmitting data in a network is provided. The data includes one or more 
segments transmitted in separate packets. The system includes a memory 
configured to store instructions and a processor configured to execute the 
instructions. The instructions cause the processor to generate a data packet 
in accordance with one protocol, with some additional constraints on its 
formatting as specified by additional instructions that are also a part of the 
system. 

In yet another implementation consistent with the present invention, a 
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computer-readable medium that stores instructions executable by one or 
more processors is provided. The instructions cause the processor to gen- 
erate a data packet in accordance with one protocol, with some additional 
constraints on its formatting as specified by additional instructions that are 
also stored in the computer- readable medium. 

In still another implementation consistent with the present invention, a 
method is provided for formatting a UDP packet with additional constraints 
and an additional pseudo-header field within the data payload field of the 
UDP packet. 

In a further implementation consistent with the present invention, a de- 
vice for transmitting one or more data packets is provided. The device in- 
cludes logic configured to generate packets for transmission, such that the 
packets are in accordance with the specifications of one protocol and are 
also in accordance with one or more additional constraints imposed by the 
teachings of this invention upon the design of the device. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute 
a part of this specification, illustrate an embodiment of the invention and, 
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together with the description, explain the invention. In the drawings, 

Fig. 1 illustrates an exemplary network in which systems and methods 

consistent with the present invention may be implemented; 

Fig. 2 illustrates an exemplary configuration of a communication device 

and network peer of Fig. 1 in an implementation consistent with the present 

invention; 

Fig. 3 illustrates exemplary diagram of a communications protocol used 
by a communication device or network peer of Fig. 1 in an implementation 
consistent with the present invention; 

Fig. 4 illustrates an exemplary structure of a Transmission Control Pro- 
tocol (TCP) packet header; and 

Fig. 5 illustrates an exemplary structure of a Internet Protocol (IP) 
packet header; and 

Fig. 6 illustrates an exemplary structure of a Data Link Protocol packet 
header; and 

Fig. 7 illustrates an exemplary structure of a User Datagram Protocols 
(UDP) packet, formatted in accordance with the teachings of the present 
invention. 
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DETAILED DESCRIPTION 

The following detailed description of the invention refers to the accompa- 
nying drawings. The same reference numbers in different drawings identify 
the same or similar elements. Also, the following detailed description does 
not limit the invention. Instead, the scope of the invention is defined by the 
appended claims and equivalents. 

Systems and methods consistent with the present invention permit com- 
munication devices of limited capabilities, such as those with very restricted 
memory resources that are unable to store the large number of instructions, 
or that are unable to contain the large logic circuitry, required for peforming 
procedures in accordance with two or more protocols, to process and respond 
to packets in accordance with network protocols. The communication devices 
may accomplish this feat by using the same set of instructions or the same 
logic circuitry to perform the procedures in accordance with two or more 
distinct protocols. The network peers may facilitate this by formatting the 
packets generated in accordance with one protocol subject to one or more 
additional formatting constraints according to this invention. 
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EXEMPLARY NETWORK 

Fig. 1 is an exemplary network 100 in which systems and methods consis- 
tent with the present invention may be implemented. The network 100 may 
include communication devices 110 and may also include network peers 120 
connected to a communication network 130. Three communication devices 
110 and three network peers 120 have been shown in Fig. 1 for simplicity. In 
practice, the network 100 may include more or less communication devices 
110 and more or less network peers 120. 

It should be noted that a communication device 110 may perform the role 
of a network peer 120 at various times in the same conversation or different 
conversations and vice versa. In other words, communication devices 110 
may perform the functions described below as being performed by network 
peers 120. Similarly, network peers 120 may perform the functions described 
as being performed by the communication devices 110. 

The network 130 may include one or more data communication networks, 
such as the Internet, an intranet, a wide area network (WAN), a local area 
network (LAN), or the like. In one implementation consistent with the 
present invention, the network 130 includes a packet-based network that op- 
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erates according to a communications protocol, such as Transmission Control 
Protocol (TCP), User Datagram Protocol (UDP) and all related protocols, 
as specified in "Requirements for Internet Hosts - Communication Layers," 
RFC1122, ftp://ftp.isi.edu/in-notes/rfcll22.txt, October 1989. 

Each of the communication devices 110 or network peers 120 may include 
a computer device, such as a personal computer, server, laptop, personal 
digital assistant (PDA), etc., a computer system, such as a system or logic 
on a chip, an electronic device, or a similar device with or without extensive 
computational and/or memory resources. The communication devices 110 or 
network peers 120 may connect to the network 130 via wired, wireless or opti- 
cal communication paths. In one implementation consistent with the present 
invention, the communication devices 110 or network peers 120 connect to 
the network 130 using a data link protocol, such as the Serial Line Internet 
Protocol (SLIP), Ethernet, or Token Ring. The communication devices 110 
or network peers 120 may communicate over the network 130 via a virtual 
circuit, connection or socket. 

Fig. 2 is an exemplary diagram of components of a communication device 
110 or network peer 120 in an implementation consistent with the present 
invention. The communication device 110 may include a bus 210, a processor 
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220, a local memory 230, an input device 240, an output device 250, and a 
communication interface 260. The bus 210 may include one or more busses or 
conductors that connect together one or more of the components of the com- 
munication device 110. The processor 220 may be any type of conventional 
processor or microprocessor that interprets and executes instructions. 

The local memory 230 may be a large or small capacity computer-readable 
medium that stores information and instructions for use by the processor 220. 
A computer-readable medium may include one or more memory devices, 
such as a random access memory (RAM), a read only memory (ROM), or 
another type of dynamic or static storage device, and/or carrier waves. In one 
implementation consistent with the present invention, the local memory 230 
includes a small capacity memory device capable of storing a small amount 
of information, less than the information typically included in a packet or in 
a set of packets. 

The input device 240 may include any conventional mechanism that per- 
mits a user to input information into the communication device 110, such 
as a keyboard, a key pad, a mouse, a microphone, a data acquisition device, 
a sensor, etc. The output device 250 may include any conventional mecha- 
nism that outputs information to the user, including a display, a speaker, a 
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transducer, an actuator, etc. The communication interface 260 may include 
any transceiver-like mechanism that enables the communication device 110 
to communicate with the other devices and systems. For example, the com- 
munication interface 260 may include mechanisms for communicating via a 
network, such as a network 130. 

As will be described in detail below, a communication device 110 or net- 
work peer 120, consistent with the present invention, that contains insuffi- 
cient resources to perform the necessary data packetization and transport 
protocol procedures in accordance with two or more protocol specifications 
may communicate over a network, such as network 130, that requires and/or 
mandates the use of such protocols and respond to packets transmitted in ac- 
cordance with any one of two or more protocols. The communication device 
110 or network peer 120 may perform these tasks in response to processor 
220 executing sequences of instructions contained in a computer-readable 
medium, such as the local memory 230. 

The instructions may be read into local memory 230 for another computer- 
readable medium or from another device via the communication interface 
260. Execution of the sequences of instructions contained in local memory 
230 causes processor 220 to perform processes that will be described later. 
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Alternatively, hardwired circuitry may be used in place of or in combination 
with software instructions to implement processes consistent with the present 
invention. For example, the components of the communication device 110 
may be fully implemented in silicon via a combination of logic gates. Thus, 
the present invention is not limited to any specific combination of hardware 
circuitry and software. 

EXEMPLARY COMMUNICATION PROTOCOL 

Fig. 3 is an exemplary diagram of a communications protocol 300 used 
by a communications device 110 in an implementation consistent with the 
present invention. The communications protocol 300 includes an application 
layer 310, a transport layer 320, a network layer 330, and a data link layer 
340. The application layer 310 may include the applications or programs that 
initiate the communication. The application layer 310 may include several 
application layer protocols for mail, file transfer, remote access, authentica- 
tion, and name resolution. The application layer 310 may deliver data 312 
to the communication network by passing data of a packet to the transport 
layer 320 along with the socket of the destination packet. 

The transport layer 320 may establish a virtual circuit, a connection, or 
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a socket between the source and the destination of the packet. Further, the 
transport layer 320 may break the packet 312 from the application layer 310 
into one or more packets, or segments. The transport layer 320 may attach 
a header 322 and trailer 324 onto the data field containing the packet 312, 
or a packet from 326, in accordance with the specifications of the relavant 
transport protocol. For example, the header 322 and trailer 324 may be in 
accordance with Transmission Control Protocol (TCP). As a further example, 
the header 322 and trailer 324 may be in accordance with the User Datagram 
Protocol (UDP). The transport layer 320 passes the packet to the network 
layer 330 along with the IP address of the destination. 

The network layer 330 may accept the packet from the transport layer 320 
and prepare the packet for the data link layer 340 by converting the IP address 
into a physical address, such as a Media Access Control (MAC) address. The 
network layer 330 may fragmenting the packet if necessary into the required 
sizes, to create one or more packets, or fragments. The network layer 330 
may generate packets called datagrams by attaching, to the data field, an IP 
header 332 and trailer 334 onto the packets from the transport layer 320 in 
accordance with the specifications of the relavant protocol. For example, this 
header 332 and trailer 334 may be in accordance with the Internet Protocol. 
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Further, the header 332 and trailer 334 may be in accordance with some 
other protocol. The network layer 330 passes the datagram to the data link 
layer 340. 

The data link layer 340 may include a data link protocol, such as Ethernet, 
Token Ring, Asynchronous Transfer Mode (ATM), Fiber Distributed Data 
Interface (FDDI), Synchronous Optical Network (SONET), or X.25, that is 
responsible for reliably moving the data across the communications network 
130. The data link layer 340 might fragment the packet into one or more 
data link packets, if necessary. The data link layer 340 converts the datagram 
into its own format, which may include adding, to the data field, a header 
342 that includes source and destination MAC addresses and a trailer 344 
that includes checksum data. The header 342 and trailer 344 may be in 
accordance with any one or any other datalink protocol. 

Four layers have been shown in Fig. 3 for simplicity. In practice, the 
communication device may have more or less number of layers than as shown 
in Fig. 3. 

Figs. 4-7 are detailed diagrams of the headers 322-342, respectively, in 
an implementation consistent with the present invention. As shown in Fig. 
4, the header 322 in accordance with Transmission Control Protocol (TCP) 
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includes a source port field, a destination port field, a sequence number field, 
an acknowledge number field, a header length field, a flags field, a window 
field, a checksum field, and an urgent pointer field. The source port and 
destination port fields include data that identify the source and destination 
of a data packet. The sequence number field includes data used to assure 
the order and delivery of the packet at the destination. The acknowledge 
field includes data that identifies the next byte of the data that the source 
expects to receive from the destination. 

The header length field includes data that identifies the length of the 
header 322. The reserved field may be used for future expansions. The flags 
field may include several flags, such as urgent, acknowledge, push, reset, 
synchronize, and finish flags. The urgent flag indicates whether the data in 
the urgent pointer field is valid. The acknowledge flag indicates whether the 
data in the acknowledgement number field is valid. The push flag indicates 
whether the accompanying data should be passed on to the application at 
the destination in an expedited manner. The reset flag indicates whether 
the connection should be reset. The synchronize flag is used to establish an 
initial agreement on the sequence numbers. The finish flag indicates whether 
the source has finished sending data. 
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The window field includes data that identifies the amount of space the 
destination has available for storage of unacknowledged data. The checksum 
field includes a checksum value that may cover both the header 322 and the 
data 312. The urgent pointer field includes data that identifies whether this 
packet should take priority over the normal data stream. 

Referring to Fig. 5, the header 332 formatted according to the Internet 
Protocol includes a version field, a header length field, a type of service field, 
a total length field, an identification field, a flags field, a fragment offset field, 
a time to live field, a protocol field, a header checksum field, a source address, 
and a destination address. The version field includes data that identifies the 
version of the protocol being used. The header length field includes data 
that identifies the length of the header 332. The type of service field includes 
data that identifies the quality of service to be given to the datagram by the 
network 320. 

The total length field includes data that identifies the length of the data- 
gram (i.e., the headers 322 and 332 and data 312). The identification field 
includes data used to reassemble a fragmented datagram at the destina- 
tion. The flags field may include one or more flags that identify, for example, 
whether the datagram may be fragmented. The fragment offset field includes 
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data that identifies the starting point in relation to the start of the original 
sent packet. 

The time to live field includes a count value that identifies the number of 
hops/links over which the packet may be routed. The protocol field includes 
data that identifies the type of transport protocol (e.g., Internet Control 
Message Protocol (ICMP), Internet Group Managament Protocol (IGMP), 
Transmission Control protocol or User Datagram Protocol (UDP)) to be used 
on the datagram at the destination. The header checksum field includes a 
checksum value that covers the header 332. The source and destination fields 
include addresses, such as Internet addresses, of the source and destination 
respectively. 

Referring to Fig. 6, the header 342 includes a destination address field, 
a source address field and a type code field. The source and destination 
address fields include addresses such as Ethernet addresses, for the source 
and destination, respectively. The type code field includes data that identifies 
the data link protocol used to connect the source and destination. 

Now referring to Fig. 7, the header 322 in accordance with User Data- 
gram Protocol (UDP) includes a source port field, a destination port field, 
a datagram length field, and a checksum field. The source port and desti- 
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nation port fields include data that identify the source and destination of 
a data packet. The datagram length field includes data that specifies the 
lenght of the UDP datagram. The checksum field contains data that is used 
to assure the validity of the data contained in the packet. The data field 
follows the header field. Consistent with the elements of present invention, 
the data field may be constrained to carry a pseudo-header field. 

EXEMPLARY PROCESSING 

A communication device 110 or a network peer 120 consistent with the 
present invention, may transmit packets formatted to be in accordance with 
any one of two or more protocols. As an example, a packet may be transmit- 
ted to be in accordance with TCP. As a further example, a packet may be 
transmitted to be in accordance with UDP. Further, in accordance with the 
principles consistent with the present invention, the packet may be formatted 
according one or more additional formatting constraints. 

For example, the UDP packet may be constrained to carry a pseudo- 
header field. One exemplary pseudo-header field is depicted in Fig 7. Fig. 
7 shows a pseudo-header containing 6 sub-fields, 710, 720, 730, 740, 750 
and 760. These fields may be generated for transmission with constraints 
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additional to the constraints of the UDP protocol. For example, the fields 
may be constrained as follows : 

• Pseudo-Header field 710 is assigned a value consistent with the ex- 
pected length of the reply UDP packet that would be generated by the 
destination device in reply to this packet; 

• Pseudo-Header field 720 is assigned the value 0x00 0x00; 

• Pseudo-Header field 730 is assigned the value hexadecimal 0x00 0x10; 

• Pseudo-Header field 740 is assigned an arbitrary value; 

• Pseudo-Header field 750 is assigned a value derived by calculating a 
checksum of the packet in accordance with the TCP checksum algo- 
rithm, by interpretting the packet that is formatted in accordance with 
the UDP protocol using the packet format specified by the TCP pro- 
tocol; 

• Pseudo-Header field 760 is assigned an arbitrary value. 

Consistent with the teachings of this invention, when a packet is received 
by a communication device 110 or network peer 120, it performs the pro- 
cedures relavant to the appropriate protocol as indicated by the protocol 
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type field in the header which specifies the formatting rules applicable to 
this packet. Additionally, consistent with the teachings of this invention, the 
communication device 110 or network peer 120 would process the pseudo- 
header according to one or more additional formatting rules. For example, 
the packet may be specified as a UDP packet. The communication device 
110 or network peer 120 receiving it may accept the packet in accordance 
with the UDP procedures. Subsequently it may extract the pseudo-header 
from the data field of the UDP packet, and perform the following procedures: 

• Pseudo-header field 710 may be compared with the UDP length field 
originally transmitted; 

• Pseudo-header field 720 may be compared with a value derived from a 
computation on the UDP checksum field orginally transmitted; 

• Pseudo-header field 730 may be compared with a value of hexadecimal 
0x00 0x18 or 0x00 0x19; 

• Pseudo-header field 740 may be ignored; 

• Pseudo-header field 750 may be compared with the result of a compu- 
tation involving the checksum of the packet computed according to the 
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UDP procedures and the checksum of the packet computed according 
to TCP procedures; 

• Pseudo-header field 760 may be ignored; 

In addition to the above, in accordance with the teachings of the present 
invention , some elements of the application layer 310 using the transport 
connection may be arranged to have certain properties constraining their 
design and selection in a manner that it facilitates this invention. As an 
example, the application layer protocol may be modified or altered to allow 
the application layer protocol to ignore a speficied number of octets of data 
field which are reserved for use for the pseudo-header. 

It should be noted that the present invention is not limited to TCP and 
UDP protocols, and may be applied to any set of two or more protocols. Fur- 
ther, the present invention may be applied to any packetization procedures 
at any or all of the layers of the protocols. Also, the present invention may be 
applied to any or all packetization protocols that are part of an architecture 
that use more or less number of layers. 

Further, hardwired circuitry may be used in place of or in combination 
with software instructions to implement processes consistent with the present 
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invention. For example, the functions performed by the components of the 
communication device 110 or the network peer 120 may be fully or partially 
implemented via a combination of logica gates formed in silicon. Thus, the 
present invention is not limited to any specific combination of hardware cir- 
cuitry and software. 

The scope of the invention is defined by the following claims and their 
equivalents. 

WHAT IS CLAIMED IS: 

1. A method for transmitting data in the form of packets, each packet in- 
cluding a header and a data field including at least one pseudo-header, 
the method comprising: 

formatting the packet header in accordance with the specifications of 
the one protocol; 

formatting a pseudo-header within the data field of the packet in ac- 
cordance with one or more additional constraints; 
transmitting a data packet including a segment of data, a header and 
a pseudo-header to a receiving device; 

receiving at least one reply packet from the receiving device, formatted 
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in accordance with the one protocol; 

determining the validity of the received packet based on at least one 
additonal processing step after reception of the packet in accordance 
with the one protocol. 

2. A method of claim 1, wherein the data packet transmitted is formatted 
in accordance with the specifications of User Datagram Protocol UDP. 

3. A method of claim 1, wherein the data packet transmitted has a pseudo- 
header within the data field. 

4. A method of claim 3, wherein the fields of the pseudo-header are gen- 
erated according to additional constraints. 

5. A method of claim 1, wherein the transmitting includes: 
transmitting the data packet using Transmission Control Protocol (TCP). 

6. A method of claim 1, wherein the transmitting includes: 
transmitting the data packet using User Datagram Protocol (UDP). 

7. A method of claim 4, where the generating includes: 

generating the at least one field of the pseudo-header in accordance 
with additional constraints. 
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8. A system for transmitting data in a network, the data including at least 
one segment transmitted in at least one packet, the system comprising: 
a memory configured to store instructions; and 

a processor configured to execute instructions to : 
generate at least one field of at least one pseudo-header after the pro- 
tocol header and before the protocol data field; and 
implement constraints on the formatting of the at least one field of the 
psedo-header. 

9. A system of claim 8, wherein at least one reply to the transmitted 
packet is received and processed. 

10. A system of claim 9, wherein the processor performs at least one addi- 
tional checking step on the pseudo-header contained within the packet 
data fields upon reception of the reply to the transmitted packet. 

11. A computer- readable medium having stored thereon a plurality of se- 
quences of instructions, said sequences of instructions including in- 
strucitons which, when executed by at least one processor, cause said 
processor to perform the steps of: 

generating at least one field of a pseudo-header after the protocol header 
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and before the protocol data field; and 

implementing constraints on the formatting of the at least one field of 
the pseudo-header. 

12. A computer-readable medium of claim 11, wherein at least one reply 
to the transmitted packet is received and processed. 

13. A computer-readable medium of claim 12, wherein the reply receieved 
in response to a transmitted packet is verified by performing at least 
one computation using the pseudo-header field contained within the 
protocol data field. 

14. A computer-readable medium of claim 11, wherein the transmitting 
includes: 

transmitting packets in accordance with the Transmission Control Pro- 
tocol (TCP). 

15. A computer-readable medium of claim 11, wherein the transmitting 
includes: 

transmitting packets in accordance with the User Datagram Protocol 
(UDP). 
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16. a computer-readable medium of claim 12, wherein the reply is received 
in accordance with the Transmission Control Protocol (TCP). 

17. a computer-readable medium of claim 12, wherein the reply is received 
in accordance with the User Datagram Protocol (UDP). 

18. A method of analyzing the header of one protocol in the context of the 
header of at least one other protocol, the method comprising: 
identifying the prefix portion of the header of the one protocol that is 
common with the corresponding prefix portion of the at least one other 
protocol; and 

identifying a next portion of the header of the one protocol that differs 
from the corresponding next portion of the header of the at least one 
other protocol; and 

computing at least one constraint that is to be applied to the processes 
which can generate packets in accordance with the at least one other 
protocol. 

19. A method of claim 18, wherein the computing of the at least one con- 
straint is done so that the packet generated in accordance with the at 
least one other protocol with the further addition of the at least one 

27 



constraint will satisfy the requirements of the one protocol. 

20. A method of claim 19, wherein the the computing of the at least one 
constraint is done so that the packet generated in accordance with the 
at least one other protocol with the further addition of the at least 
one constraint will substantially satisfy the requirements of the one 
protocol. 

21. A method of transmitting data as data packets, the method comprising: 
receiving packets formatted in accordance with one protocol; and 
applying them to the processing procedures designed in accordance 
with an other one protocol; and 

generating replies to be transmitted in response to the received packets; 
and 

transmitting the replies into the network. 

22. A method of claim 21, wherein the one protocol is Transmission Control 
Protocol (TCP). 

23. A method of claim 22, wherein the one other protocol is User Datagram 
Protocol (UDP). 
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24. A method of claim 21, wherein the one protocol is User Datagram 
Protocol (UDP). 

25. A method of claim 24, wherein the other one protocol is Transmission 
Control Protocol (TCP). 

26. A device of claim 20, further comprising: 

logic configured to receive packets in accordance with at least one pro- 
tocol; and 

logic configured to generate a reply and to transmit the reply into the 
network in accordance with at least one protocol, 
logic configured to insert at least one pseudo-header field in the trans- 
mitted packet in accordance with at least one additional constraint. 
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ABSTRACT 

Methods and systems for processing data packets enable a communica- 
tion device having limited memory to participate in network protocols. One 
communicating device formats packets in accordance with the specifications 
of one or two or more communication protocols, with one or more additional 
constraints, and transmits it to an other communication device. The other 
communication device performs a specified processing of the received packet 
to generate a reply packet in response to the received packet, which conforms 
to the one of two or more communication protocols, while also satisfying one 
or more additional formatting constraints. 
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